Subject: Flow control comments

From: [email-masked]
Date: Fri, 9 Jul 93 08:57:43 EDT

I fully agree that the pacing request belongs at the beginning of a
window - I think David's summary misrepresented the actual implementation
on that point (not that the implementation really matters anyway).
I also agree with Bernie's statement that the receiving side sends a
pacing response whenever it's ready (implementation-specific) as
opposed to requiring it on the first WAN-bound frame after the request
was received.

If we all decide CWI should replace ENTERBUSY (which seems reasonable
to me at this point), I think it should definitely be allowed to flow
unsolicited.  In general some flavor of unsolicited IPM will allow
the receiving node more control over congestion and its buffer space.

Bernie, I didn't understand well your questions about DWSI and IWSI:
> Is there any reason why either DWSI and IWSI cannot be set while the
> window is closed?
 Are you proposing that somehow the sender keep a non-zero window size
 integer while in the "closed" state, which the receiver can adjust via
 DWSI and IWSI before signalling the sender to jump "open" back to this
 value?  I'd assumed "closed" meant a window size of zero and that an
 unsolicited IPM from the receiver with IWSI set was the only way to
 get the sender out of the closed state.

> Without negotiation how does a sending side determine to half or
> increment the receiving sides windows?
 As I understand it the sending side must simply obey what the receiver
 says via the IWSI and DWSI bits, which are set only in pacing responses.

> If you ask a peer to increment to a value it does not support does it
> ignore the request or take down the circuit?
 I would think the sender would be happy to go to the max window size
 our "siglet" determines should be supported - it's just a counter
 controlling when the pacing request bit is set.

Peter Gayek

---

From: "Bernard Brady" <[email-masked]>
Date: Fri, 9 Jul 93 12:31:53 EDT

Peter,

> get the sender out of the closed state.

I was interpretting the CWI as replacing the ENTERBUSY/EXITBUSY for
closing and opening  the window but not adjusting the actual window
opening size.   CWI  on/off would be used to signal either busy or not. 
I then saw the DWSI or IWSI as the mechanism to modify the actual size
of the window opening  in either a closed or open state.   I didn't see
CWI as setting the actual window size to zero and then having to
increment it when the receiver goes from busy to non-busy.  Zeroing the
window  is most likely how IBM is using it.  I also agree that a better
summary of  the actual implementation would clarify things.

This brings up a point in that the ENTERBUSY/EXITBUSY allows end points
to close the window without modifying the size.  By eliminating
these messages we loose this functionality.  My take is that we need to
retain this  functionality in whatever we decide.

Bernie